fix(github): /status reports credential liveness, not just presence - #809

Both from @ux-lead's review of #808 (msg 52276).

1. `POST /token` is a seventh route that hits GitHub —
   `getInstallationIdForRepo` and `getInstallationToken` both do — and it
   still flattened everything but 404 into a 500. It is also where the
   defect bites hardest: the endpoint's whole job is credentials, so the
   caller most likely to see an upstream 401 there is someone already
   debugging a credential failure, and a 500 tells them to retry. Now
   mapped, with `message` kept alongside the mapped body since CLI and
   driver callers read that key — additive, nothing that parses the old
   shape breaks.

   `/status` is left on its 500 deliberately, with a comment saying why:
   it reads env and signs a JWT locally, touches no upstream, so a throw
   there really is our fault.

2. `does not pass the 401 through to the caller` asserted only
   `not.toBe(401)`, so it stayed green under the exact 502→500 mutation
   its name implies it guards — a 500 isn't a 401 either. Now pins
   `toBe(502)` as well. Re-ran their M3: 2 red before, 3 red after.

9/9 at node@22 v22.23.1, tsc:check clean.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

`GET /api/github/status` is the one endpoint whose job is to diagnose the
GitHub credential, and it answered `configured: true` off
`!!process.env.GITHUB_PAT`. Through the 2026-08-04 outage it therefore
reported the configuration healthy while every proxied call returned 401 —
failing in the direction that ends the search. Three seats were blocked and
one concluded the fault was its own seat (msg 52256); this endpoint would
have agreed with it.

A SECOND predicate, not a corrected one (@ux-lead, msg 52286).
`isPatConfigured` gates six sites asking two different questions: four ask
"should I attempt this?", where presence is right and a network round-trip
per request is not; `/status` asks "is it working?". Putting I/O inside
`isPatConfigured` would fix one and tax the other four.

`checkPatLiveness` probes `/rate_limit`, which GitHub documents as not
counting against quota, so a diagnostic may call it freely.

Three answers, not two: `live: null` for unreachable. Reporting `false`
when GitHub could not be reached would send an operator to rotate a working
credential — a diagnostic that guesses confidently is the defect being
removed, not a smaller copy of it.

`/status` must NOT adopt #808's mapper, and the test pins it: a 502 on a
dead credential makes "the credential is dead" indistinguishable from "the
diagnostic is broken", reintroducing at the diagnostic the exact collapse
#808 removed from the seven proxying routes. A dead credential is a
successful diagnosis, so it answers 200.

Stacked on #808 (`68b51262`) — same file, and branching off main would have
conflicted. Merge after it.

6 new tests, 22/22 across the github route suites, tsc:check clean.
Mutations: revert to presence-only 5 red; unreachable-reported-as-dead
1 red; /status adopting the 502 2 red.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

The liveness probe added in the previous commit collapsed every 403 to
`rejected`. GitHub overloads 403 for both "credential refused" and "you are
being throttled", and the mapper eighty lines away already knew that — it
tests `x-ratelimit-remaining` before falling through to the credential
branch. The probe skipped that test, so a rate-limited but perfectly valid
PAT reported `credentialLive: false` and would send an operator to rotate a
working credential: the exact outcome the tri-state `live: null` exists to
prevent, arriving through the one branch that wasn't guarded.

Found by @ux-lead in review (msg 52320), against my own PR.

The predicate is now shared rather than duplicated, in its own module.
Putting it on GitHubAppService failed loudly and usefully: route tests
legitimately mock that service wholesale, which deleted a piece of pure
routing logic and turned the mapper's 502 into a 500. A predicate over an
HTTP status and a header bag should not be reachable only through a
stateful service object.

`rate_limited` carries `live: null` for the same reason `unreachable`
does — a throttled probe genuinely does not know.

Also records the scope limit @ux-lead named and neither of us can measure
while the shared PAT is dead: `/rate_limit` is not scope-gated, so
`accepted` proves GitHub recognises the token, not that it is authorized
for what the seven proxying routes do. A PAT regenerated without `repo`
scope or SSO re-authorization would read healthy here and 403 everywhere
else — this method's own version of the bug it fixes, one layer up.
Docstring says so, and says how to settle it at the next rotation.

Verified: 25/25 across all three github route suites (4 new), tsc:check
clean, node@22. Mutations, each blob-hashed both ways:
  - probe collapses every 403 to rejected (the reported bug) -> 3 red
  - predicate ignores the secondary-limit header             -> 1 red
  - route mapper loses the shared disambiguation             -> 1 red,
    caught by the pre-existing mapper test, so the refactor is
    behavior-preserving and guarded rather than merely untested.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

@ux-lead's finding 3 (msg 52320): `credentialLive` is derivable from
`credentialStatus` and is the lossy one. Adding `rate_limited` made it
slightly lossier — `live === null` now merges unreachable with throttled —
so the interface says plainly that `status` is canonical and `live` is a
projection for humans reading the JSON.

Docstring only, per their "not worth a rework".

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>